Embodiments of the present system and method relate generally to electronic communications in a healthcare setting. Particularly, certain embodiments relate to providing scalable, procedure-centric management of patient data across multiple networked sites.
Healthcare facilities often employ certain types of digital diagnostic imaging modalities, such as computed tomography, magnetic resonance imaging, ultrasound imaging, and X-ray imaging. These digital diagnostic imaging modalities use a common format for image data, known as Digital Imaging and Communications in Medicine (DICOM). The evolution of the DICOM format facilitated the development and expansion of Picture Archiving and Communication Systems (PACS). Use of the DICOM semantics provided by the DICOM format has become the standard method for managing imaging data access in healthcare institutions.
The DICOM standard enumerates a command set, data formats, interface specifications, communication protocols, and command syntax. DICOM sets forth Information Objects (types of data, such as computerized tomography, magnetic resonance, x-ray, ultrasound, etc.), Service Classes (actions with data, such as send, receive, print, etc.), and data transmission protocols. DICOM application services provide the ability to transfer images and image related data between DICOM applications. A DICOM service-object pair (SOP) is used to push and/or pull information between DICOM applications.
As standalone systems in healthcare settings, PACS have a number of roles in data management. PACS receive image data sets fed from imaging modality devices. PACS manage storage systems for data persistency, managing both short-term and long-term storage. PACS accept query requests from client applications, enabling those client applications to retrieve specified data. PACS may also interface with other healthcare information systems.
Using PACS as centralized servers for DICOM format queries has greatly improved diagnostic image access and distribution in a heterogeneous systems environment. In the recent past, the PACS have been able to scale with the growth of healthcare networks and maintain an acceptable level of service. FIG. 1 illustrates a prior art system 100 for scaling access to a centralized PACS 110 across an enterprise that contains multiple sites 120, 121, 122, 123, 124 & 125. In FIG. 1, each site 120-125 connects directly with the PACS 110.
However, it is increasingly challenging to provide an image access solution across an entire healthcare network as these healthcare enterprises grow larger and more far-flung. There is a trend towards improved healthcare information accessibility in an expanding geographic scope: from departmental, to enterprise and inter-enterprise, and to regional and Independent Delivery Network environments.
However, scaling a central PACS to multiple sites can become extremely difficult as the number of sites significantly increases. A number of factors may prevent a single system from being scaled across multiple sites and enterprises, such as: data ownership; workflow complexity; system availability; and technology challenges.
One factor preventing enterprise scaling of a central PACS is data ownership. One reason that data ownership is a factor preventing enterprise scaling of a central PACS is that different institutions may not want to place data into a central repository. Also, different institutions may not be able to place data into a central repository for technical or regulatory reasons. Generally speaking, healthcare institutions are amenable to sharing data with other healthcare institutions, but these same healthcare institutions prefer to control access to data. The boundaries between and among healthcare institutions may create barriers for the creation of a central data repository.
Another factor preventing enterprise scaling of a central PACS is workflow complexity. Generally, workflow is another name for the pool of actions to be taken that originate when a radiologist or other healthcare professional places an order for work to be performed by an imaging modality on a particular patient and eventually saved on a PACS. Healthcare institutions create data management processes for handling workflow known as workflow models. Different healthcare institutions may adopt different workflow models. One potential consequence of these different workflow models is that a single procedure, which is common to many institutions, may be treated differently by different workflow models. These different workflow models for a single, common procedure create a challenge to provide efficient workflow management functions and tools to cope with various needs across multiple enterprises.
Still another factor preventing enterprise scaling of a central PACS is system availability. A single PACS or even a network of PACS may only be available to a limited number of users at a time. Thus, whether a user is archiving, retrieving, or otherwise managing data, the system resources of the PACS must be allocated among all the users demanding PACS access. When more healthcare institutions or other participating user sites are given access to one PACS or a PACS network, the system availability and reliability decreases. Scaling PACS access to an entire enterprise may decrease system availability dramatically.
Yet another factor preventing enterprise scaling of a central PACS can be generally referred to as technical complexity. When an image management system is scaled to provide service across an enterprise or multiple enterprises, response time, system serviceability, network configuration and many other factors become more complicated to manage.
While each of the above factors presents substantial challenges to scaling a central PACS, none of these factors absolutely limits the system scalability. That is, it is possible that some part of each of the factors may be addressed by, for example, scaling system resources in proportion to the scaling of the PACS service area. However, the cost of increasing system resources to provide for the scalability of a single PACS can quickly offset the benefit of improved image availability and accessibility in the large-scale environment. A more efficient approach for system scalability is needed.
Aside from the factors described above that present challenges to PACS scalability, there is another kind of challenge to providing PACS access across a single enterprise or multiple enterprises. This other challenge may be understood as the difference between how a typical clinical user sees data versus how a typical data management system sees data. The difference between these points of view is that a typical clinical user has a procedure-centric approach and a data management system has a device-centric or data-centric approach.
For example, a clinical user expects to view images in a clinical record oriented way. That is, a clinical user considers that the hierarchy of clinical data will roughly follow the model of the actual interaction a patient has with the healthcare institution, which generally is: patient, visit, order, service request, and procedures. This hierarchy is the backbone of the procedure-centric approach. The patient may make multiple visits. Each visit may result in one or more orders, which in turn may result in one or more service request per order. The service requests in turn generate one or more procedures. A procedure represents the most basic imaging service unit that is orderable, interpretable, and chargeable. Images are produced and reported in a procedure for certain diagnostic purpose, according to the procedure's specification.
An important aspect of the procedure-centric model is its universality. That is, clinical users at different healthcare institutions will apply the procedure-centric model as the hierarchy they use to consider clinical data, regardless of how the data is actually handled by their local data management system. Thus, the procedure-centric model represents a commonly known and applied hierarchy for clinical data. A procedure-centric approach for image access potentially allows clinical users at different healthcare institutions to view and interpret images in common with each other.
On the other hand, the DICOM information model organizes images and other SOP instances in the following hierarchy: patient, study, series, and SOP instance. Each of these hierarchical levels is specific to the DICOM standard, and together they form the backbone of the device-centric model. The hierarchical levels of DICOM are queried using a query/retrieve information model as part of the DICOM standard. While the DICOM model has made significant improvements to standardize the data storage structure and to ease data exchange, the DICOM model does not necessarily reflect a clinical record oriented, or procedure-centric, organization of clinical data. The procedure-centric model requires more data management logic, clinical intelligence and process flexibility than the DICOM model provides.
Although the hierarchical levels in the procedure-centric model may seem superficially similar to the hierarchical levels in the device-centric model, the two hierarchies are substantially different. For example, a DICOM study does not necessarily match to a procedure. For the purposes of data management, error reconciliation, and process complexity, several studies may be produced in a single procedure, and a number of procedures may share the same study. In addition, a study may include a number of series or a number of DICOM objects such as Gray Scale Presentation State (GSPS), Key Image Node (KIN), and Structured Report (SR) objects. These DICOM objects may also be known as data descriptors. In the DICOM model, the client system must interpret which objects, studies, or series are relevant and how they should be used. The DICOM model for data management directly exposes a “data store view” to the clinical user, which may not reflect the clinical record context of the images.
As presented in the previous description, there is a need for scalable healthcare data management systems. There is a need for these scalable healthcare data management systems to overcome the challenges associated with data ownership, workflow complexity, system availability, and technology management. There is a further need to present data to clinical users in a procedure-centric format.